Peer-assisted deployment of resources in a network

ABSTRACT

In particular embodiments, a server computing device receives one or more inputs specifying a software module and one or more portions of a network. Each of the portions of the network includes multiple client devices. For each of the client devices in a portion of the network, the server computing device determines whether the client device meets one or more criteria. For at least one portion of the network having a client device meeting the one or more criteria, the server computing device selects the client device as a master device and provides the software module to the master device. The master device is operable to download the software module from one or more server computing devices, provide the software module to the other client devices in the portion of the network, and provide status information to the server computing device.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of application Ser. No. 14/185,549titled “Peer-Assisted Deployment of Resources in a Network,” filed Feb.20, 2014, which is incorporated herein by reference.

TECHNICAL FIELD

This disclosure relates generally to information handling systems and,more particularly, to networks having multiple client devices.

BACKGROUND

As the value and use of information continues to increase, individualsand businesses seek additional ways to process and store information.One option available to users is information handling systems. Aninformation handling system generally processes, compiles, stores,and/or communicates information or data for business, personal, or otherpurposes thereby allowing users to take advantage of the value of theinformation. Because technology and information handling needs andrequirements vary between different users or applications, informationhandling systems may also vary regarding what information is handled,how the information is handled, how much information is processed,stored, or communicated, and how quickly and efficiently the informationmay be processed, stored, or communicated. The variations in informationhandling systems allow for information handling systems to be general orconfigured for a specific user or specific use such as financialtransaction processing, airline reservations, enterprise data storage,or global communications. In addition, information handling systems mayinclude a variety of hardware and software components that may beconfigured to process, store, and communicate information and mayinclude one or more information handling systems, data storage systems,and networking systems.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsfeatures and advantages, reference is now made to the followingdescription, taken in conjunction with the accompanying drawings, inwhich:

FIG. 1 is a block diagram of selected elements of an informationhandling system;

FIG. 2 is an example of a network environment; and

FIG. 3 an example of a network environment including multiple clientdevices.

DETAILED DESCRIPTION

The detailed description set forth below is intended as a description ofvarious configurations of the subject technology and is not intended torepresent the only configurations in which the subject technology may bepracticed. The appended drawings are incorporated herein and constitutea part of the detailed description. The detailed description includesspecific details for the purpose of providing a thorough understandingof the subject technology. However, it will be apparent to those skilledin the art that the subject technology may be practiced without thesespecific details. In some instances, well-known structures andcomponents are shown in block diagram form in order to avoid obscuringthe concepts of the subject technology.

In the following description, details are set forth by way of example tofacilitate discussion of the disclosed subject matter. It should beapparent to a person of ordinary skill in the field, however, that thedisclosed embodiments are exemplary and not exhaustive of all possibleembodiments.

For the purposes of this disclosure, an information handling system mayinclude an instrumentality or aggregate of instrumentalities operable tocompute, classify, process, transmit, receive, retrieve, originate,switch, store, display, manifest, detect, record, reproduce, handle, orutilize various forms of information, intelligence, or data forbusiness, scientific, control, entertainment, or other purposes. Forexample, an information handling system may be a personal computer, aPDA, a consumer electronic device, a network storage device, or anothersuitable device and may vary in size, shape, performance, functionality,and price. The information handling system may include memory, one ormore processing resources such as a central processing unit (CPU) orhardware or software control logic. Additional components or theinformation handling system may include one or more storage devices, oneor more communications ports for communicating with external devices aswell as various input and output (I/O) devices, such as a keyboard, amouse, and a video display. The information handling system may alsoinclude one or more buses operable to transmit communication between thevarious hardware components.

Herein, a computer-readable non-transitory storage medium or media mayinclude one or more semiconductor-based or other integrated circuits(ICs) (such, as for example, field-programmable gate arrays (FPGAs) orapplication-specific ICs (ASICs)), hard disk drives (HDDs), hybrid harddrives (HHDs), optical discs, optical disc drives (ODDs),magneto-optical discs, magneto-optical drives, floppy diskettes, floppydisk drives (FDDs), magnetic tapes, solid-state drives (SSDs),RAM-drives, SECURE DIGITAL cards or drives, any other suitablecomputer-readable non-transitory storage media, or any suitablecombination of two or more of these, where appropriate. Acomputer-readable non-transitory storage medium may be volatile,non-volatile, or a combination of volatile and non-volatile, whereappropriate.

Particular embodiments are best understood by reference to FIGS. 1-3,wherein like numbers are used to indicate like and corresponding parts.

FIG. 1 illustrates an example information handling system 100. Inparticular embodiments, one or more information handling systems 100perform one or more steps of one or more methods described orillustrated herein. In particular embodiments, one or more informationhandling systems 100 provide functionality described or illustratedherein. In particular embodiments, software running on one or moreinformation handling systems 100 performs one or more steps of one ormore methods described or illustrated herein or provides functionalitydescribed or illustrated herein. Particular embodiments include one ormore portions of one or more information handling systems 100. Herein,reference to an information handling system may encompass a computingdevice, and vice versa, where appropriate. Moreover, reference to aninformation handling system may encompass one or more informationhandling systems, where appropriate.

This disclosure contemplates any suitable number of information handlingsystems 100. This disclosure contemplates information handling system100 taking any suitable physical form. As example and not by way oflimitation, information handling system 100 may be an embeddedinformation handling system, a system-on-chip (SOC), a single-boardinformation handling system (SBC) (such as, for example, acomputer-on-module (COM) or system-on-module (SOM)), a desktopinformation handling system, a laptop or notebook information handlingsystem, an interactive kiosk, a mainframe, a mesh of informationhandling systems, a mobile telephone, a personal digital assistant(PDA), a server, a tablet information handling system, or a combinationof two or more of these. Where appropriate, information handling system100 may include one or more information handling systems 100; be unitaryor distributed; span multiple locations; span multiple machines; spanmultiple data centers; or reside in a cloud, which may include one ormore cloud components in one or more networks. Where appropriate, one ormore information handling systems 100 may perform without substantialspatial or temporal limitation one or more steps of one or more methodsdescribed or illustrated herein. As an example and not by way oflimitation, one or more information handling systems 100 may perform inreal time or in batch mode one or more steps of one or more methodsdescribed or illustrated herein. One or more information handlingsystems 100 may perform at different times or at different locations oneor more steps of one or more methods described or illustrated herein,where appropriate.

In particular embodiments, information handling system 100 includes aprocessor 102, memory 104, storage 106, an input/output (I/O) interface108, a communication interface 110, and a bus 112. Although thisdisclosure describes and illustrates a particular information handlingsystem having a particular number of particular components in aparticular arrangement, this disclosure contemplates any suitableinformation handling system having any suitable number of any suitablecomponents in any suitable arrangement.

In particular embodiments, processor 102 includes hardware for executinginstructions, such as those making up a computer program. As an exampleand not by way of limitation, to execute instructions, processor 102 mayretrieve (or fetch) the instructions from an internal register, aninternal cache, memory 104, or storage 106; decode and execute them; andthen write one or more results to an internal register, an internalcache, memory 104, or storage 106. In particular embodiments, processor102 may include one or more internal caches for data, instructions, oraddresses. This disclosure contemplates processor 102 including anysuitable number of any suitable internal caches, where appropriate. Asan example and not by way of limitation, processor 102 may include oneor more instruction caches, one or more data caches, and one or moretranslation lookaside buffers (TLBs). Instructions in the instructioncaches may be copies of instructions in memory 104 or storage 106, andthe instruction caches may speed up retrieval of those instructions byprocessor 102. Data in the data caches may be copies of data in memory104 or storage 106 for instructions executing at processor 102 tooperate on; the results of previous instructions executed at processor102 for access by subsequent instructions executing at processor 102 orfor writing to memory 104 or storage 106; or other suitable data. Thedata caches may speed up read or write operations by processor 102. TheTLBs may speed up virtual-address translation for processor 102. Inparticular embodiments, processor 102 may include one or more internalregisters for data, instructions, or addresses. This disclosurecontemplates processor 102 including any suitable number of any suitableinternal registers, where appropriate. Where appropriate, processor 102may include one or more arithmetic logic units (ALUs); be a multi-coreprocessor; or include one or more processors 102. Although thisdisclosure describes and illustrates a particular processor, thisdisclosure contemplates any suitable processor.

In particular embodiments, memory 104 includes main memory for storinginstructions for processor 102 to execute or data for processor 102 tooperate on. As an example and not by way of limitation, informationhandling system 100 may load instructions from storage 106 or anothersource (such as, for example, another information handling system 100)to memory 104. Processor 102 may then load the instructions from memory104 to an internal register or internal cache. To execute theinstructions, processor 102 may retrieve the instructions from theinternal register or internal cache and decode them. During or afterexecution of the instructions, processor 102 may write one or moreresults (which may be intermediate or final results) to the internalregister or internal cache. Processor 102 may then write one or more ofthose results to memory 104. In particular embodiments, processor 102executes only instructions in one or more internal registers or internalcaches or in memory 104 (as opposed to storage 106 or elsewhere) andoperates only on data in one or more internal registers or internalcaches or in memory 104 (as opposed to storage 106 or elsewhere). One ormore memory buses (which may each include an address bus and a data bus)may couple processor 102 to memory 104. Bus 112 may include one or morememory buses, as described below. In particular embodiments, one or morememory management units (MMUs) reside between processor 102 and memory104 and facilitate accesses to memory 104 requested by processor 102. Inparticular embodiments, memory 104 includes random access memory (RAM).This RAM may be volatile memory, where appropriate. Where appropriate,this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, whereappropriate, this RAM may be single-ported or multi-ported RAM. Thisdisclosure contemplates any suitable RAM. Memory 104 may include one ormore memories 104, where appropriate. Although this disclosure describesand illustrates particular memory, this disclosure contemplates anysuitable memory.

In particular embodiments, storage 106 includes mass storage for data orinstructions. As an example and not by way of limitation, storage 106may include a hard disk drive (HDD), a floppy disk drive, flash memory,an optical disc, a magneto-optical disc, magnetic tape, or a UniversalSerial Bus (USB) drive or a combination of two or more of these. Storage106 may include removable or non-removable (or fixed) media, whereappropriate. Storage 106 may be internal or external to informationhandling system 100, where appropriate. In particular embodiments,storage 106 is non-volatile, solid-state memory. In particularembodiments, storage 106 includes read-only memory (ROM). Whereappropriate, this ROM may be mask-programmed ROM, programmable ROM(PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM),electrically alterable ROM (EAROM), or flash memory or a combination oftwo or more of these. This disclosure contemplates mass storage 106taking any suitable physical form. Storage 106 may include one or morestorage control units facilitating communication between processor 102and storage 106, where appropriate. Where appropriate, storage 106 mayinclude one or more storages 106. Although this disclosure describes andillustrates particular storage, this disclosure contemplates anysuitable storage.

In particular embodiments, I/O interface 108 includes hardware,software, or both, providing one or more interfaces for communicationbetween information handling system 100 and one or more I/O devices.Information handling system 100 may include one or more of these I/Odevices, where appropriate. One or more of these I/O devices may enablecommunication between a person and information handling system 100. Asan example and not by way of limitation, an I/O device may include akeyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker,still camera, stylus, tablet, touch screen, trackball, video camera,another suitable I/O device or a combination of two or more of these. AnI/O device may include one or more sensors. This disclosure contemplatesany suitable I/O devices and any suitable I/O interfaces 108 for them.Where appropriate, I/O interface 108 may include one or more device orsoftware drivers enabling processor 102 to drive one or more of theseI/O devices. I/O interface 108 may include one or more I/O interfaces108, where appropriate. Although this disclosure describes andillustrates a particular I/O interface, this disclosure contemplates anysuitable I/O interface.

In particular embodiments, communication interface 110 includeshardware, software, or both providing one or more interfaces forcommunication (such as, for example, packet-based communication) betweeninformation handling system 100 and one or more other informationhandling systems 100 or one or more networks. As an example and not byway of limitation, communication interface 110 may include a networkinterface controller (NIC) or network adapter for communicating with anEthernet or other wire-based network or a wireless NIC (WNIC) orwireless adapter for communicating with a wireless network, such as aWI-FI network. This disclosure contemplates any suitable network and anysuitable communication interface 110 for it. As an example and not byway of limitation, information handling system 100 may communicate withan ad hoc network, a personal area network (PAN), a local area network(LAN), a wide area network (WAN), a metropolitan area network (MAN), orone or more portions of the Internet or a combination of two or more ofthese. One or more portions of one or more of these networks may bewired or wireless. As an example, information handling system 100 maycommunicate with a wireless PAN (WPAN) (such as, for example, aBLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephonenetwork (such as, for example, a Global System for Mobile Communications(GSM) network), or other suitable wireless network or a combination oftwo or more of these. Information handling system 100 may include anysuitable communication interface 110 for any of these networks, whereappropriate. Communication interface 110 may include one or morecommunication interfaces 110, where appropriate. Although thisdisclosure describes and illustrates a particular communicationinterface, this disclosure contemplates any suitable communicationinterface.

In particular embodiments, bus 112 includes hardware, software, or bothcoupling components of information handling system 100 to each other. Asan example and not by way of limitation, bus 112 may include anAccelerated Graphics Port (AGP) or other graphics bus, an EnhancedIndustry Standard Architecture (EISA) bus, a front-side bus (FSB), aHYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture(ISA) bus, an INFINIBAND interconnect, a low-pin-count (LPC) bus, amemory bus, a Micro Channel Architecture (MCA) bus, a PeripheralComponent Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serialadvanced technology attachment (SATA) bus, a Video Electronics StandardsAssociation local (VLB) bus, or another suitable bus or a combination oftwo or more of these. Bus 112 may include one or more buses 112, whereappropriate. Although this disclosure describes and illustrates aparticular bus, this disclosure contemplates any suitable bus orinterconnect.

FIG. 2 illustrates an example configuration of networked informationhandling systems (e.g. client devices and servers). In particularembodiments, one or more client devices 220 and one or more servers 240are connected via network 210. Network 210 may be a public network or aprivate (e.g. corporate) network. Additionally, network 210 may, forexample, be a Local Area Network (LAN), a Wide Area Network (WAN), awireless network, the Internet, an intranet or any other suitable typeof network. In particular embodiments, network 210 may include one ormore routers for routing data between client devices 220 and/or servers240. A device (e.g., a client device 220 or a server 240) on network 210may be addressed by a corresponding network address including, forexample, an Internet protocol (IP) address, an Internet name, a WindowsInternet name service (WINS) name, a domain name or other system name.In particular embodiments, network 210 may include one or more logicalgroupings of network devices such as, for example, one or more sites(e.g. customer sites) or subnets. As an example, a corporate network mayinclude potentially thousands of offices or branches, each with its ownsubnet (or multiple subnets) having many devices. One or more clientdevices 220 may communicate with one or more servers 240 via anysuitable connection including, for example, a modem connection, a LANconnection including the Ethernet or a broadband WAN connectionincluding DSL, Cable, Ti, T3, Fiber Optics, Wi-Fi, or a mobile networkconnection including GSM, GPRS, 3G, or WiMax.

Client device 220 may be a desktop computer, a laptop computer, a tabletcomputer, a handheld device, a mobile phone, a kiosk, a vending machine,a billboard, or any suitable information handling system. In particularembodiments, a client device 220 is an embedded computer and may haveflash memory (e.g. a solid state drive) instead of a hard disk drive. Inparticular embodiments, a client device 220 is a thin client havinglimited processing capabilities and limited storage, and such a thinclient may require minimal management and updates. A client device 220may communicate with a server 240 via one or more protocols such asHypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure(HTTPS), File Transfer Protocol (FTP), Common Internet File System(CIFS), Independent Computing Architecture (ICA) protocol (developed byCitrix Systems, Inc.), Remote Desktop Protocol (RDP) (developed byMicrosoft Corporation), or any suitable protocol or combination ofprotocols.

A server 240 may include one or more of: a computing device, a desktopcomputer, a laptop computer, a database, a corporate server, arepository server, a configuration application server, a domain namesystem (DNS) server, a dynamic host configuration protocol (DHCP)server, a virtual machine (e.g., VMware® Virtual Machine), a desktopsession (e.g., Microsoft Terminal Server), a published application(e.g., Microsoft Terminal Server), or any suitable information handlingsystem. As an example, a private (e.g. corporate) network may include adevice manager server and a repository server each configured tocommunicate with multiple client devices 220 across one or more domains,sites, or subnets of network 210. In particular embodiments, a server240 may include one or more servers, or functions of one or moreservers. A client device 220 may access software resources provided by aserver 240 such as, for example, operating systems, add-ons, content, orany other suitable data, applications, or images. In particularembodiments, a client 220 may access resources provided by a server 240only after providing suitable authentication information. Alternatively,a server 240 may provide software or other resources automatically toone or more client devices 220.

It may be desirable, in the case of a private (e.g. corporate) networkincluding multiple sites or subnets to deploy software (including, e.g.,all or part of one or more operating systems, applications, add-ons, ordata) to one or more client devices 220 across one or more sites orsubnets. The client devices 220 may, for example, be located remotelyfrom one or more servers 240 (including, e.g., device managers orresource repositories), and as such, there may be challenges indeploying software or other resources to the client devices. As anexample, limited connectivity or limited speed due to bandwidthconstraints or network latencies may create delays in deployingsoftware. As another example, remote sites or subnets may not includemanaged components or may not have any personnel with informationtechnology expertise necessary to implement software deployment toclient devices at the sites or subnets. Additionally, as the size ofoperating system images or other content (e.g. videos) increases,deploying software or other data to remote sites or subnets may befurther delayed. These issues may be further exacerbated in the case ofembedded computers such as thin clients, which may have limitedprocessing capability and limited storage space. Traditional approachesinvolving using a static remote software repository for each subnet orsite may not be feasible due to cost or management and monitoringrequirements.

In particular embodiments, one or more servers 240 of a network 210 mayinclude a device manager that may manage one or more client devices 220(e.g. thin clients) of one or more sites or subnets of the network. Thedevice manager may, for example, be a software-based management toolthat allows for software imaging, software updates, and softwareconfigurations to be deployed to the clients from one or more servers.The device manager may also perform any other suitable managementfunction to manage client devices including, for example, enabling orperforming (e.g. automatically) device discovery, tracking of assets(e.g. hardware or software inventory) at client devices, monitoring thestatus or health of client devices, applying one or more policies toclient devices (including, e.g., network settings of the clientdevices), or remote administration and shadowing of client devices. Thedevice manager may deliver any suitable resources including, forexample, operating systems, add-ons, content, or any other suitabledata, applications, or images to one or more thin client devices 220 ofnetwork 210.

In particular embodiments, the device manager may deploy resources tothin client devices across multiple subnets or sites in a network via apeer-assisted process that involves selecting one or two (or anysuitable number) of thin clients in each subnet or site as a “master”device, and then using the master device or devices to deploy resourcesto other client devices within the respective subnet or site. The masterdevices serve as the peers from which other client devices within asubnet or site may be deployed resources. The number of master devicesin each site or subnet may, for example, be configurable (e.g. a settingat the device manager). The device manager may control all or part ofthe process. The device manager of a network may determine which thinclients in a subnet or site of the network may be designated as masterdevices based on one or more characteristics of the thin clients in thesubnet or site. As an example, the device manager may determine which ofthe thin clients in the subnet or site have recently checked in (e.g.via a network status update) with the device manager. In particularembodiments, those clients who have most recently checked-in are bettercandidates to be designated as master devices than those clients whoselast check-in was before some predetermined amount of time, such as thepast 24 hours, or those clients who have not checked in during aparticular time period or who have missed a certain number of check-ins.As other examples, the device manager may select as master devices onlythose thin clients having more than a certain amount of storage space(e.g. sufficient to store required software or data for deployment givencurrent usage of the thin client), having more than a certain amount ofavailable processing ability (e.g. to be able to process the deploymenttasks), having more than a certain network bandwidth capability (e.g. toefficiently download the deployment software or data), having requiredserver components (e.g. to serve as a subnet- or site-specificrepository), or being capable of performing delayed updates (e.g. todownload an image in the background). The device manager may, inparticular embodiments, store a list (e.g. a database) of candidatedevices in each subnet or site that may be chosen to be a master devicebased on one or more criteria including those listed herein. From thislist, the device manager may select one or two (or any suitable number)of thin clients in each subnet or site to be the master devices for thesubnet or site. The device manager may, in particular embodiments,select the master devices within a subnet or site upon receiving auser's command (e.g. via a user interface, described herein) to deploy asoftware package to client devices in the subnet or site via thepeer-assisted process. Although reference is made to thin client devicesin one or more subnets or sites, the peer-assisted deployment processmay be used with any suitable client device (including, e.g.,smartphones or tablet computers).

FIG. 3 illustrates an example embodiment of a network architecture fordeployment of resources to multiple thin clients across two subnets. Inthe example of FIG. 3, device manager 302 and repository 304 (which areexamples of servers 240) are located remotely from thin client devicesin two subnets, 306 and 320, of a network (e.g. a network 210, which maybe a private corporate network). Device manager 302 may manage thedeployment of resources from repository 304 to one or more of the thinclients in subnet 306 or subnet 320. In particular embodiments, devicemanager 302 and repository 304 may be part of a single server, and inyet other embodiments, they may each be part of different servers.Repository 304 may, for example, be an HTTPS, HTTP, FTP, orCIFS-compatible repository, and the protocol used to deploy resourcesmay be selected by an administrator interacting with the device manager302. In the example of FIG. 3, device manager 302 may select two thinclients in each subnet to be the master devices for the subnet. Thinclients 308 and 310 are selected by device manager 302 to be the masterdevices for subnet 306, and thin clients 322 and 324 are selected to bethe master devices for subnet 320.

Once the device manager selects the thin clients that are to be masterdevices in each subnet or site of interest, the master devices areimaged from a repository (e.g. residing on one or more servers 240 ofnetwork 210). In the example of FIG. 3, thin clients 308 and 310 insubnet or site 306 and thin clients 322 and 324 in subnet or site 320receive resources for deployment (e.g. software or data) from repository304. Once imaging of the master devices in each subnet or site iscomplete (and the imaged master devices are each converted into asubnet- or site-specific repository), the device manager is notified byeach of the imaged master devices. At this point, the device manager maythen communicate with and notify one or more secondary devices in eachsubnet or site (e.g. those thin clients in the subnet or site that arenot the master devices) that they may access the resources to bedeployed at the master device or devices in their respective subnet orsite. In particular embodiments, a particular number (e.g., half) of thesecondary devices in a subnet may be notified that they may accessresources at a first master device in the subnet or site, and theremainder of the secondary devices in the subnet or site may be notifiedthat they may access resources at a second master device in the subnetor site. The secondary devices of a subnet or site may be imaged inmultiple cycles or batches. A subnet or site may include any suitablenumber of master devices (including, e.g., only one), and the secondarydevices in the subnet or site may be notified that they may accessresources at a particular master device in the subnet or site accordingto any suitable algorithm or scheme. Additionally, a master device maybe assigned to no more than a predetermined number of (e.g. 7) secondarydevices for updating at any moment in time. In particular embodiments, asecondary device in a subnet or site may only access resources to bedeployed from its assigned master device in the subnet or site afterproviding authentication information (e.g. a stored key or password) tothe master device. Additionally, the master devices in each subnet orsite (and/or the device manager for the network) may include a whitelistof approved thin clients in the subnet or site and/or a blacklist ofthin clients that may not access resources at the master devices. Inparticular embodiments, a master device and a secondary device in aparticular subnet or site may communicate via an encrypted connection(e.g. using the Secure Shell protocol), such that any deployment ofresources from the master device to the secondary device is secure. Inother embodiments, a master device and its secondary devices maycommunicate via an unencrypted connection. Once the secondary devices ineach subnet or site have connected to their respective master devices inthe subnet or site and completed downloading of the resources to bedeployed (e.g. an operating system, an application, or an image), thedevice manager may be notified. In particular embodiments, the devicemanager may communicate with the master devices and/or the secondarydevices in each subnet or site to maintain up-to-date (e.g. dynamic)status information including which devices are the master devices in agiven subnet or site and the status of the deployment of resources toeach of the secondary devices (e.g. a download progress indicator forthose secondary devices accessing resources at a master device). If asecondary device fails to obtain resources (e.g. an image) from a masterdevice, the secondary device may retry some predetermined number oftimes (e.g., once, twice, or three times); if the secondary device stillfails after retrying, it may report failure to the device manager. Onceall of the secondary devices in a subnet or site have completed theirupdating (e.g. downloading of the resource to be deployed from a masterdevice) or have reported failure, the device manager may instruct one ormore of the master devices in the subnet or site to delete the resource(e.g. an image) that was downloaded to the master devices. In thismanner, the master devices of a subnet or site may be “cleaned up” toenable them to have space for future deployment of resources. Inparticular embodiments, a master device of a subnet need not haveadditional space for downloading and storing a resource (e.g. anoperating system or image), as the master device may directly capture orcopy a “live” version of the resource (e.g. the operating system orimage) currently running on the master device and provide it to otherclient devices in its subnet or site.

In particular embodiments, or more newly-updated client devices of anetwork (e.g. across one or more subnets) may be used to update otherclient devices in the network. For example, once a secondary device isupdated (e.g. from a master device within its subnet), the secondarydevice may then automatically communicate with the device manager,notifying the device manager that it has been updated. The devicemanager may then select this secondary device to be a new master devicefor the subnet, and may proceed to instruct as-yet-unupdated secondarydevices in the subnet to obtain images (or other resources) from thisnew master device. In this manner, the deployment of resources (e.g.software packages or images), beginning from a single repository (e.g.repository 304), may proceed at a geometric pace, without consuming anexcessive amount of bandwidth between the servers of the network (e.g.the device manager and repository) and the client devices of the subnetsor sites of the network. As described herein, the device manager maycreate a list (e.g. a database) of candidate client devices in eachsubnet or site that may be chosen to be a master device (e.g. a clientdevice capable of being a subnet- or site-specific repository). Inparticular embodiments, the device manager may also maintain a list, foreach subnet or site, of client devices that are to become subnet- orsite-specific repositories after being imaged or updated (e.g. by amaster device via the peer-assisted deployment process). The list may,for example, indicate a minimum number of client devices (e.g. 7) in asubnet or site that are selected to be “new” master devices afterimaging or updating. These “new” master devices may then become part ofa pool of master devices in the subnet or site that may work to image orupdate all remaining secondary client devices in the subnet. As anexample, the “original” or first set of master devices in a subnet orsite may become “root master” devices that image or update a first setof secondary devices. The secondary devices in this first set may then,in turn, become “new” master devices and then image or update anadditional set of secondary devices, and so on in a geometricprogression. This process may significantly reduce the overall time toimage or update an entire set of client devices in a subnet or site(e.g. location). The algorithm for selecting client devices for the listof future subnet- or site-specific repositories may vary based on anysuitable criteria including, for example, the class of subnet, a userexclusion list, and/or the other criteria described herein, such as timesince last check-in or available free space.

In particular embodiments, the peer-assisted deployment process mayoccur at a memory block level (in contrast to, for example, a file levelor software package level), and each master device may receive one ormore memory blocks that are then deployed to one or more secondarydevices. In particular embodiments, repository 304 may be a servercomputing device associated with a cloud services provider and may, forexample, be located remotely from device manager 302. Such a cloudservices provider may provide operating systems, images, or any othersuitable resource to be deployed to one or more client devices of anetwork (including, e.g., a private network).

In particular embodiments, a device manager of a network may include auser interface that allows a user (e.g. a system administrator) toadjust one or more settings associated with the deployment of resourcesto one or more client devices in one or more subnets or sites of thenetwork. The user interface may, for example, allow the user to selectone or more packages (including any suitable combination of updates,configurations, or images) to be deployed in one or more subnet or sitesof the network. The user interface may display relevant informationassociated with a package including, for example, release version, datecreated, size, platform, operating system, status, or any other suitableinformation. The user interface may also allow the user to search forand specify which subnet or subnets (or sites) of the network willreceive the deployment of the packages during, for example, a particulartime period (e.g. a maintenance interval). The user interface maydisplay one or more subnets or sites available for selection by the userand may include each subnet or site's IP address, a description (e.g. anickname or a site name) of the subnet or site, the number of devicesassociated with the subnet or site, the status of the subnet or site,and/or any other suitable information regarding the subnets or sites ofthe network. The particular time period or maintenance interval fordeployment may, for example, be set to a default value or may bespecified by a user using a start time/date and a stop time/date (andmay be set as a recurring event). In particular embodiments, a user mayinput scheduling preferences that may govern the deployment of resourcesto client devices. In particular embodiments, the user may specify themaximum number of simultaneous packages being deployed, the number ofminutes to wait to determine whether a client device has timed out, themaximum number of times to attempt rescheduling a failed packagedeployment, or any other suitable scheduling preference. The user mayalso specify that the time zone for the maintenance interval (defined bystart and stop dates/times) be that of: (1) the device manager (e.g.302), (2) the repository (e.g. 304), or (3) each device receiving adeployment (e.g. a thin client master device or secondary device). Oncethe stop time of the maintenance interval is reached (in the relevanttime zone), then the process will stop further deployments and may, forexample, restart the process during the next scheduled maintenanceinterval (e.g. the next day at the same start time). A user may also“pause,” “play,” or cancel a deployment process; for example, a user mayhalt (e.g. temporarily or permanently, in the case of a cancellation) anin-process (or scheduled) deployment, and a user may also cause a halteddeployment to resume via the user interface. In particular embodiments,if a client device is added to a subnet or site during a maintenanceinterval (e.g. after the start date/time and before the stop date/time),then the client device may be included in the peer-assisted deploymentprocess and may be updated along with the existing secondary devices inthe subnet or site. However, if a client device is added after amaintenance interval and before the start of another maintenanceinterval for the subnet or site, then the client device must either beupdated with the desired resources in a different fashion (e.g. manuallyby a system administrator using a Drag and Drop method) or must wait tobe updated until the next peer-assisted deployment maintenance intervalfor the subnet or site.

In particular embodiments, the device manager, upon receiving a usercommand for deployment (e.g. a pressing of a “deploy” button in a userinterface), may check a database (e.g. a database or list of candidatemaster devices) to determine how many candidate devices in theuser-selected subnet or site may act as a master device or subnet- orsite-specific repository. If the device manager does not find at leastone suitable device within a particular selected subnet or site, thenthe device manager may warn the user (e.g. via a user interface) thatthere is no suitable device in the subnet or site that may serve as apeer. This may indicate to the user that issues specific to the subnetor site may need to be resolved. The user interface may prompt the userto deselect the subnet or site before proceeding with deploymentinstructions for other subnets or sites. The device manager may thenpopulate a peer-to-peer command table with the deployment packages forthose devices that belong to the selected subnets or sites having atleast one candidate master device. In particular embodiments, the devicemanager (e.g. a user interface of the device manager) may receive aregular “refresh device” command. This refresh command may containdetails of a certain number (e.g. a predetermined but configurablenumber, such as 25) candidate master devices per subnet or site. Asdisclosed herein, the device manager may chose a particular number (e.g.one or two) of master devices from the candidates for a particularsubnet or site and proceed with the peer-assisted deployment processdescribed herein.

As disclosed herein, in particular embodiments, the device manager maycommunicate with the master devices and/or the secondary devices in eachsubnet or site to maintain up-to-date (e.g. dynamic) status information.This status information may, for example, be displayed to a user (e.g. asystem administrator for a network) in communication with the devicemanager (e.g. via a user interface). That status information for asubnet or site may be any suitable information including which devicesare the master devices in a given subnet or site and the status of thedeployment of resources to each of the secondary devices (e.g. adownload progress indicator for those secondary devices accessingresources at a master device). The status information may include anindication of whether a particular device (e.g. a master device orsecondary device) or a particular subnet or site has completed itsupdating (and if not, what the progress is, e.g., as a percentage) orwhether there has been a failure along the way. The status informationmay be at any suitable granularity (e.g. device-level, subnet- orsite-level, or overall deployment-level). Example status indicators fora subnet or site may indicate that a master device is being selected,that a master device is being imaged, or that one or more secondarydevices are being imaged. Example status indicators for a particularmaster device within a subnet or site may indicate that the particularmaster device is being imaged, that the particular device failed to beselected (e.g. by the device manager, automatically) as a master device,or that the particular device is imaging one or more secondary devices.In particular embodiments, the device manager receives a report or list(e.g. dynamically generated or regularly generated) of failed or “bad”master devices in each of one or more subnets or sites of the network,and an administrator of the network may then manually purge or updatethose devices. Alternatively, the “bad” or failed master devices may beautomatically purged from a list of candidate master devices, and anyother suitable actions may be taken by the device manager with respectto these failed master devices. Example status indicators for a group(or batch) of one or more secondary devices may indicate an assignedmaster device within the subnet or site (e.g. if multiple master devicesare chosen within the subnet or site), a group indicator (e.g. ifmultiple groups of secondary devices exist within the subnet or site),the number of devices in the group, the number of devices in the groupthat have been successfully imaged, the number of devices in the groupthat have failed to be imaged, and the number of devices in the groupwhose imaging is in process. In particular embodiments, master devices,secondary devices, or both may also report errors due to lack ofsufficient storage space (e.g. to receive an image that is beingdeployed), lack of sufficient network connectivity, or any downloaderrors that may have occurred at the devices. Any suitable statusinformation may be communicated between the device manager and thedevices of the network across multiple subnets or sites.

Herein, “or” is inclusive and not exclusive, unless expressly indicatedotherwise or indicated otherwise by context. Therefore, herein, “A or B”means “A, B, or both,” unless expressly indicated otherwise or indicatedotherwise by context. Moreover, “and” is both joint and several, unlessexpressly indicated otherwise or indicated otherwise by context.Therefore, herein, “A and B” means “A and B, jointly or severally,”unless expressly indicated otherwise or indicated otherwise by context.

The scope of this disclosure encompasses all changes, substitutions,variations, alterations, and modifications to the example embodimentsdescribed or illustrated herein that a person having ordinary skill inthe art would comprehend. The scope of this disclosure is not limited tothe example embodiments described or illustrated herein. Moreover,although this disclosure describes and illustrates respectiveembodiments herein as including particular components, elements,feature, functions, operations, or steps, any of these embodiments mayinclude any combination or permutation of any of the components,elements, features, functions, operations, or steps described orillustrated anywhere herein that a person having ordinary skill in theart would comprehend. Furthermore, reference in the appended claims toan apparatus or system or a component of an apparatus or system beingadapted to, arranged to, capable of, configured to, enabled to, operableto, or operative to perform a particular function encompasses thatapparatus, system, component, whether or not it or that particularfunction is activated, turned on, or unlocked, as long as thatapparatus, system, or component is so adapted, arranged, capable,configured, enabled, operable, or operative.

What is claimed is:
 1. A method comprising: managing by a device managerdeployment of one or more resources from a repository; for each of oneor more portions of a network, for each of a plurality of client devicesin the one or more portions of the network, determining whether one ormore of the plurality of client devices meets one or more criteria;storing the one or more of the plurality of client devices that meet theone or more criteria as one or more candidate devices in a list;selecting at least one of the one or more candidate devices from thelist as a master device for the one or more portions of the network;converting the master device to a designated repository, wherein thedesignated repository is associated with a designated portion of the oneor more portions of the network; receiving a notification from thedesignated repository after completion of the conversion of the masterdevice to the designated repository; assigning up to a threshold of theplurality of client devices that are not the master device to thedesignated repository; downloading at least one of the one or moreresources to the designated repository; notifying the assigned clientdevices that the at least one of the one or more resources isaccessible; receiving a connection notification for the assigned clientdevices that successfully connected to the designated repository;imaging at least one of the assigned client devices with the at leastone of the one or more resources; receiving status informationassociated with imaging of the at least one of the one or more resourcesat the at least one assigned client devices; selecting by the devicemanager at least one of the one or more assigned client devices based onthe status information as a new master device, wherein the statusinformation indicates if imaging was successful; and instructing by thedevice manager at least one of the one or more assigned client devicesthat has yet to be successfully imaged as indicated by the statusinformation to obtain the at least one of the one or more resources fromthe new master device.
 2. The method of claim 1, wherein the one or moreresources are selected via a graphical user interface.
 3. The method ofclaim 1, wherein the at least one of the one or more resources comprisesone or more of the following: an operating system; an image; an add-on;or an update.
 4. The method of claim 1, wherein: the at least one of theone or more resources comprises an image or an operating system; thedesignated repository is currently running the operating system or theimage; and the designated repository is operable to provide theoperating system or the image to any one or more assigned client devicesby copying the running operating system or the image.
 5. The method ofclaim 1, wherein the one or more portions of the network comprise one ormore subnets.
 6. The method of claim 1, wherein the one or more portionsof the network comprise one or more sites.
 7. The method of claim 1,wherein the assigned client devices comprise thin client devices.
 8. Themethod of claim 1, wherein the criteria include one or more of: anetwork bandwidth capability; a number of missed check-ins with theserver computing device; an amount of available storage; or an amount ofavailable processing capacity.
 9. An information handling systemcomprising: one or more processors; and a memory coupled to theprocessors comprising instructions executable by the processors, theprocessors being operable when executing the instructions to: manage bya device manager deployment of one or more resources from a repository;for each of one or more portions of a network, for each of a pluralityof client devices in the one or more portions of the network, determinewhether one or more of the plurality of client devices meets one or morecriteria; store the one or more of the plurality of client devices thatmeet the one or more criteria as one or more candidate devices in alist; select at least one of the one or more candidate devices from thelist as a master device for the one or more portions of the network;convert the master device to a designated repository, wherein thedesignated repository is associated with a designated portion of the oneor more portions of the network; receive a notification from thedesignated repository after completion of the conversion of the masterdevice to the designated repository; assign up to a threshold of theplurality of client devices that are not the master device to thedesignated repository; download at least one of the one or moreresources to the designated repository; notify the assigned clientdevices that the at least one of the one or more resources isaccessible; receive a connection notification for the assigned clientdevices that successfully connected to the designated repository; imageat least one of the assigned client devices with the at least one of theone or more resources; receive status information associated withimaging of the at least one of the one or more resources at the at leastone of the assigned client devices; select by the device manager atleast one of the one or more assigned client devices based on the statusinformation as a new master device, wherein the status informationindicates if imaging was successful; and instruct by the device managerat least one of the one or more assigned client devices that has yet tobe successfully imaged as indicated by the status information to obtainthe at least one of the one or more resources from the new masterdevice.
 10. The information handling system of claim 9, wherein the oneor more resources are selected via a graphical user interface.
 11. Theinformation handling system of claim 9, wherein the at least one of theone or more resources comprises one or more of the following: anoperating system; an image; an add-on; or an update.
 12. The informationhandling system of claim 9, wherein: the at least one of the one or moreresources comprises an image or an operating system; the designatedrepository is currently running the operating system or the image; andthe designated repository is operable to provide the operating system orthe image to any one or more assigned client devices by copying therunning operating system or the image.
 13. The information handlingsystem of claim 9, wherein the one or more portions of the networkcomprise one or more subnets.
 14. The information handling system ofclaim 9, wherein the one or more portions of the network comprise one ormore sites.
 15. The information handling system of claim 9, wherein theassigned client devices comprise thin client devices.
 16. Theinformation handling system of claim 9, wherein the criteria include oneor more of: a network bandwidth capability; a number of missed check-inswith the server computing device; an amount of available storage; or anamount of available processing capacity.
 17. One or morecomputer-readable non-transitory storage media embodying software thatis operable when executed to: manage by a device manager deployment ofone or more resources from a repository; for each of one or moreportions of a network, for each of a plurality of client devices in theone or more portions of the network, determine whether one or more ofthe plurality of client devices meets one or more criteria; store theone or more of the plurality of client devices that meet the one or morecriteria as one or more candidate devices in a list; select at least oneof the one or more candidate devices from the list as a master devicefor the one or more portions of the network; convert the master deviceto a designated repository, wherein the designated repository isassociated with a designated portion of the one or more portions of thenetwork; receive a notification from the designated repository aftercompletion of the conversion of the master device to the designatedrepository; assign up to a threshold of the plurality of client devicesthat are not the master device to the designated repository; download atleast one of the one or more resources to the designated repository;notify the assigned client devices that the at least one of the one ormore resources is accessible; receive a connection notification for theassigned client devices that successfully connected to the designatedrepository; image at least one of the assigned client devices with theat least one of the one or more resources; receive status informationassociated with imaging of the at least one of the one or more resourcesat the at least one of the assigned client devices; select by the devicemanager at least one of the one or more assigned client devices based onthe status information as a new master device, wherein the statusinformation indicates if imaging was successful; and instruct by thedevice manager at least one of the one or more assigned client devicesthat has yet to be successfully imaged as indicated by the statusinformation to obtain the at least one of the one or more resources fromthe new master device.
 18. The information handling system of claim 17,wherein the one or more resources are selected via a graphical userinterface.
 19. The information handling system of claim 17, wherein theat least one of the one or more resources comprises one or more of thefollowing: an operating system; an image; an add-on; or an update. 20.The information handling system of claim 17, wherein: the at least oneof the one or more resources comprises an image or an operating system;the designated repository is currently running the operating system orthe image; and the designated repository is operable to provide theoperating system or the image to any one or more assigned client devicesby copying the running operating system or the image.